Networks keep track of events that occur for a variety of collaborative network devices. The network typically uses a computer to gather and share information with other computers, network devices, and applications. There are many programs the network can use to manage network elements, including applications that are capable of polling elements for status, capturing traps and error messages, providing reports, and performing a variety of other duties. Polling is a common, if not particularly efficient way to ask for status from an element. Polling asks network elements, “Are you there? Are you ok?” Processor resources are consumed as polling asks for status of each network element until it answers or times out, oblivious of the actual state of the network element. As polling takes up processor resources, it can only ask a limited number of network elements for status. Because of polling limitations, more efficient strategies like eventing are being explored.
Eventing is the term used for the gathering and/or sharing of information between network elements through the use of notifications. Event tracking is a way of managing the notifications that come into a central location from network elements, and using information in the notifications to make changes, corrections, and updates to the network and network elements. Event tracking allows the network to monitor and manage network elements based on activity within the network, removing the inefficiencies of polling.
A variety of activities may be monitored and managed through eventing. Events may include system information and status, log entries for transactions and subscriptions, data updates, errors and error codes, failures, and other relevant data. There can be special requirements for eventing, depending on the network elements involved. The requirements can be based on the type of protocol needed to communicate and how the network element provides information. Additional requirements might include how to handle real-time, near-real time, and historic notifications and communication.
The network may manage events from a communication server or computer. The ability to correlate, consolidate, and react to events as they occur directly impacts management efficiency. Some networks have started using open source databases as they are fast and scalable. However, many popular open source databases (e.g., Cassandra) don't natively support eventing, meaning that the databases are unable to provide eventing without extra help. Most open source databases also lack multi-protocol support (e.g., Session Initiation Protocol-SIP, Hypertext Transfer Protocol-HTTP, Lightweight Directory Access Protocol-LDAP). Multi-protocol support is required by many network products to communicate with many different types of network elements.
Lack of native support with open source databases can be addressed with a variety of strategies including polling, busy-wait, interrupt-driven I/O or interrupt requests (IRQs), and web service eventing. Polling is the typical low-level check previously described. Busy-wait checks the status of a network element until it is ready to communicate, at which point the network element provides status. As with polling, processor resources are wasted when network elements provide no response or slow response. IRQs ask the network element to stop what it is doing to give status once. The way in which IRQs halt operations and only ask once is not efficient. Internet Protocol (IP) addressing also has to be done carefully to avoid conflicts and errors. Web service eventing is intended to provide more efficient and reliable message delivery than the strategies previously listed. However, web eventing has limitations for large deployments since notification paths must be set up manually. Web eventing is unable to provide IP multicast, lacks the ability for recipients to forward messages to others, and lacks end-to-end security and Quality of Service (QoS) guarantees.
A remote collaborative network device using a protocol like SIP may not communicate effectively unless the protocol has an open channel and is active through firewalls, routers, and session border controllers (SBCs). An open channel may be used to deliver notifications of changed data to keep collaborative network devices in synchronization. Allowing only a single protocol to be used as the only way to manipulate data is inefficient for adjacent servers who may use RESTful access methods without concerns about firewall, router, and SBC blockages.
More efficient and less expensive strategies are needed for security, reliability, and accessibility for networks that have network elements and collaborative network devices requiring multi-protocol support for both stateful and evented information.
A strategy that provides robust and consistent universal access for all network elements and devices with eventing for a Cassandra or other open-source database including the ability to manage multiple protocols is desired. Additional features and advantages of embodiments of the present invention will become more readily apparent from the following description, particularly when taken together with the accompanying drawings.